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T ransmissiontofi fi(SB/I^ from a hub 

station to a plurality of remote units. The data, transmitted 
over the satellite link, uses the digital video broadcast 
(DVB) protocol. A field in the DVB header is used to 
indicate the location of the start of a new TCP/IP data packet 
within the DVB data. Use of a field in the DVB header to 
indicate the location of the start of a new TCP/IP data packet 
supports variable location of TCP/IP data within a DVB 
frame, and therefore more efficient use of the DVB band- 
width. 
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TRANSMISSION AND RECEPTION OF TCP/ 
IP DATA OVER A WIRELESS 
COMMUNICATION CHANNEL 

RELATED APPLICATIONS 

This is a continuation-in-part application of an application 
entitled TRANSMISSION OF TCP/IP DATA OVER A 
WIRELESS COMMUNICATION CHANNEL, Ser. No. 
09/407,646, filed Sep. 28, 1999, now abandoned, which 
claims priority to a provisional application entitled SYS- 
TEM AND METHOD FOR WIRELESS INTERNET 
SERVICE, Serial No. 60/151,282, filed Aug. 27, 1999, each 
of which is hereby incorporated by reference. 

FIELD OF THE INVENTION 

The invention relates generally to transmission of Internet 
data over a wireless communication channel. More 
particularly, this invention relates to transmission of Internet 
data using digital video broadcast format over a satellite 
communication channel. 

BACKGROUND OF THE INVENTION 

Explosive growth of the Internet, including Internet 
related commerce, has greatly increased the demand for 
Internet access. This demand crosses all geographic and 
demographic boundaries, from developed urban neighbors 
and cities to remote and developing nations. Presently 
access to the Internet is typically through copper wire. In 
developed nations such infrastructure exists in the form of 
public telephone networks. However, in developing coun- 
tries and remote locations, there may not be a copper wire 
infrastructure in place, and development of such an infra- 
structure may be excessively costly, making its development 
unpractical. In addition, as Internet use increases, access 
through existing copper wires may become unacceptably 
slow due to the limited bandwidth of the copper wire and 
increased volume of Internet traffic. Because of these and 
other limitations on the existing infrastructure, a high-speed, 
reliable Internet communication service over a satellite link 
is desirable. A satellite link can provide Internet access to 
developing countries, as well as remote locations, where 
there is no copper wire infrastructure in place. Moreover, 
Internet access over a satellite link can provide an attractive 
alternative to copper wire, even if the infrastructure is in 
place, by providing high-speed, more reliable Internet 
access. 

The Internet is based on an architecture developed by the 
Defense Advanced Research Projects Agency (DARPA). 
This architecture is generally referred to as the transmission 
control protocol/Internet protocol (TCP/IP) suite. The TCP/ 
IP protocol suite is organized into four layers: network 
access layer; Internet layer; TCP layer; and process layer. 

FIG. 1 is a block diagram illustrating an exemplifying 
system for discussion of the TCP/IP model. FIG. 1 shows 
two nodes 20 and 22 connected to the Internet 24. As 
illustrated, the Internet comprises multiple subnetworks 26 
and 28. Data is transferred between subnetworks through a 
router 30. In a node, network access layer 32 provides access 
to the subnetwork to which the node is connected. At the 
network access layer, a network header 34 is added to the 
data to be sent over the subnetwork. Various standards have 
been developed for transmission of data across subnetworks, 
also referred to as Local Area Networks (LAN). These 
standards have been collected into the Institute of Electrical 
and Electronic Engineers (IEEE) 802 specification. Within 
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this specification, the IEEE 802.3 defines a LAN utilizing a 
carrier sense multiple access collision detection (CSMA/ 
CD) protocol. In CSMA/CD protocol when a node on the 
network wants to transmit data, it senses the communication 

5 channel to determine if the channel is being used. If the 
channel is in use, the node does not transmit and waits for 
a time when no traffic is sensed to transmit. The transmitting 
node also monitors the channel as it transmits to determine 
if another node transmits at the same time. If two nodes 

10 transmit at the same time, there is a collision, which both 
nodes detect. Following detection of a collision, both trans- 
mitting nodes will discontinue transmission. The nodes will 
then wait independently random periods of time and then 
attempt to retransmit. A popular implementation of the 

15 CSMA/CD protocol is the Ethernet. 

If data is to be transmitted between two nodes which are 
located on different, interconnected, subnetworks the Inter- 
net Protocol (IP) is used. At the IP layer 36, functions for 
routing across multiple networks are provided. The IP layer 

20 provides an IP header 38 which comprises the destination 
address. To facilitate movement of data between two 
subnetworks, thelmuteifSjOjfts used. The router 30 receives a 
message from one subnetwork and examines the IP header 
38 for the destination address. Knowing the destination 

25 address, the router transmits the message to the appropriate 
subnetwork where the destination node is located. 

The Transmission Control Protocol (TCP) layer 40 pro- 
vides for a reliable, error free, data exchange. The TCP layer 
40 receives a data block 42 from the process layer 44. If the 

30 data block 42 is too large, the TCP layer 40 divides the data 
block 44 into messages 46. A TCP header 48 is added to each 
message 46. The TCP header comprises a destination port, 
sequence number and checksum. The destination port iden- 
tifies which port at the destination node is to receive the 

35 message 46 transmitted. The sequence number identifies the 
individual data packets so the messages 46 can be sequenced 
in the proper order at the destination node. The checksum 
provides a method of verifying the integrity of the data 
received at the destination node. 

40 

The process layer 44 contains the logic needed to support 
various user applications. Applications which operate on top 
of the TCP/IP include, for example, Simple Mail Transfer 
Protocol (SMTP) for basic electronic mail, File Transfer 

45 Protocol (FTP) for file transfer from one system to another, 
hyper text transfer protocol ("HTTP") for transfer of Web 
pages and TELNET which provides remote login capability. 

At the destination node, the process described above is 
performed in reverse. Traffic on the subnetwork is received 

50 by the network access layer 32. The network header 34 is 
removed and the remaining data passed to the IP layer 36. At 
the IP layer, the IP header 38 is removed and examined. If 
the message is addressed to the destination node, the remain- 
ing data is passed to the TCP layer 40, otherwise the message 

ss is ignored. The TCP layer removes the TCP header 48. The 
integrity of the message 46 is then verified using the 
checksum from the TCP header 48. If the data block that was 
sent has been divided into multiple data packets, the TCP 
layer 40, using the sequence number from the TCP header 

60 48, places the messages 46 in proper order. After the TCP 
layer 40 has rebuilt the data block 42 that was transmitted, 
it passes the data block 42 to the appropriate port at the 
process layer 44. 

While the TCP/IP and Ethernet protocols are used for 

65 transmission of data on networks such as the Internet, 
Digital Video Broadcast (DVB) is used to send Motion 
Picture Expert Group (MPEG) data over a satellite link. In 
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the TCP/IP model, DVB would be located at the network 
access layer providing an interface to the physical transmis- 
sion medium comprising the satellite channel. 

The DVB protocol is the result of a market led consortium 
of public and private sector organizations in the television 5 
industry. This consortium led to the development of the 
DVB standard published by the European Telecommunica- 
tions Standard Institute (ETSI). The DVB standard describes 
the modulation and channel coding system for satellite 
digital television broadcast. This standard is compatible with 10 
the MPEG-2 coded TV services. The MPEG-2 protocol 
generates digital information separated into "data pockets." 
DVB simply receives the data pockets and places them into 
"data containers" for transmission over a wireless media. 
Within the DVB protocol, no restriction exists as to the kind 15 
of information which can be stored in these data containers. 

As digital TV continues to gain acceptance and becomes 
common place, the demand for DVB receivers will greatly 
increase. Once DVB receivers come to the market in large 
numbers, it is expected that the commonality of design for 20 
a large market will enable costs to be kept down. 

Thus, DVB can provide a cost effective means of video 
data transmission via satellite. However, no analogous 
standard, or cost effective way, has been developed to 25 
transmit TCP/IP data via satellite. 

Therefore, there is a need in the technology for a means 
for and method of transmitting TCP/IP data over a satellite 
link. 

SUMMARY OF THE INVENTION 30 

Demand for high-speed, reliable Internet access is 
increasing. This increased demand is occurring where there 
is no "copper wire" infrastructure in place, such as devel- 
oping nations and remote areas. In addition, where the 35 
"copper wire" infrastructure is in place, its capacity is often 
exceeded by the demand placed upon the system. The 
invention provides a communication system for transmis- 
sion of Internet or other TCP/IP data over a satellite link. 

One embodiment provides Internet service to a plurality 40 
of remote units in communication with a satellite. The 
satellite is also in communication with a hub station. The 
hub station is further in communication with a plurality of 
content servers. Data from the content servers is communi- 
cated to the hub station via the Internet. The hub station then 45 
transmits the content server data received from the Internet 
to the plurality of remote units over the satellite link. The 
hub station formats the data, to be transmitted over the 
satellite link, in a format compatible with the DVB standard. 

Further, a hub station receiving a block of Internet data for 50 
transmission to a plurality of remote units over a satellite 
communication channel formats the data within DVB 
frames such that fragment headers occur at variable loca- 
tions within the DVB frame. A value, stored within the DVB 

55 

frame, indicates the location of the fragment headers within 
the DVB frame. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is an block diagram illustrating an exemplifying 6Q 
system for discussion of the TCP/IP model 

FIG, 2 is a block diagram illustrating an exemplifying 
system in which the invention may be embodied. 

FIG, 3 is a diagram describing the structure of a TCP 
transport packet of a transport layer. 65 

FIG, 4 is a diagram describing the structure of an IP 
packet of a network layer. 


,292 Bl 

4 

FIG. 5 is a diagram describing the structure of an exem- 
plifying Media Access Control (MAC) data frame at the 
network access layer. 

FIG. 6 is a block diagram describing the structure of a 
Digital Video Broadcast (DVB) header of a DVB data 
frame. 

FIG. 7 is a block diagram illustrating conversion of a 
MAC data frame into a DVB data frame. 

FIG. 8 is a block diagram of a transmitter system of a hub 
station. 

FIG. 9 is a flowchart describing the steps executed in the 
conversion of a MAC data frame into a DVB data frame. 

FIG. 10 is a block diagram of a receiver system of a 
remote unit. 

FIG. 11 is a flowchart describing the steps executed in the 
conversion of a DVB data frame into a MAC data frame, 

DETAILED DESCRIPTION OF THE 
INVENTION 

FIG. 2 is a block diagram illustrating an exemplifying 
system in which the invention may be embodied. The system 
in FIG. 2 provides high-speed, reliable Internet communi- 
cation service over a satellite link. 

In particular, in FIG. 2, content servers 100 are coupled to 
the Internet 24 which is in turn coupled to a hub station 104 
such that the hub station 104 can request and receive digital 
data from the content servers 100. The hub station 104 also 
communicates via satellite 106 with a plurality of remote 
units 108A-108N. For example, the hub station 104 trans- 
mits signals over a forward uplink 110 to the satellite 106. 
The satellite 106 receives the signals from the forward 
uplink 110 and re-transmits them on a forward downlink 
112. Together, the forward uplink 110 and the forward 
downlink 112 are referred to as the forward link. The remote 
units 108A-108N monitor one or more channels which 
comprise the forward link in order to receive remote -unit- 
specific and broadcast messages from the hub station 104. 

In a similar manner, the remote units 108A-108N trans- 
mit signals over a reverse uplink 114 to the satellite 106, The 
satellite 106 receives the signals from the reverse uplink 114 
and re-transmits them on a reverse downlink 116. Together, 
the reverse uplink 114 and the reverse downlink 116 are 
referred to as the reverse link. The hub station 104 monitors 
one or more channels which comprise the reverse link in 
order to extract messages from the remote units 
108A-108N. For example, in one embodiment of the exem- 
plifying system, the reverse link carries multiple access 
channels in accordance with assignee's co-pending applica- 
tion entitled METHOD AND APPARATUS FOR MUL- 
TIPLE ACCESS IN A COMMUNICATION SYSTEM, 
application Ser. No. 09/407,639, filed Sep. 28, 1999, the 
entirety of which is hereby incorporated by reference. 

In one embodiment of the exemplifying system, each 
remote unit 108A-108N is coupled to a plurality of system 
users. For example, in FIG. 2, the remote unit 108A is shown 
as coupled to a local area network 116 which in turn is 
coupled to a group of user terminals 118A-118N. The user 
terminals 118A-118N may be one of many types of local 
area network nodes such as a personal or network computer, 
a printer, digital meter reading equipment or the like. When 
a message is received over the forward link intended for one 
of the user terminals 118A-118N, the remote unit 108 A 
forwards it to the appropriate user terminal 118 over the 
local area network 116. Likewise, the user terminals 
118A-118N can transmit messages to the remote unit 108A 
over the local area network 116. 
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In one embodiment of the exemplifying system, the packet on a parallel reverse connection. A TCP header length 

remote units 108A-108N provide access to the Internet for field 320 of 4 bits follows the piggyback acknowledgment 

a plurality of users. For example, assume that the user field 316 to indicate how many 32-bit words are contained 

terminal 118 A is a personal computer which executes in the TCP header 48. This information is needed because 

browser software in order to access the World Wide Web. 5 the header 48 includes a variable-length options field 360 

When the browser receives a request for a web page or which communicates data as may be agreed upon by the 

embedded object from the user, the user terminal 11 8A source host and destination host. 

creates a request message according to well-known tech- After several unused bits 322, the TCP header length 320 

niques. The user terminal 118 A forwards the request mes- is followed by six 1-bit flags. The first 1-bit flag is URG 324 

sage over the local area network 116 to the remote unit 1Q which is set to 1 if an urgent pointer 356 is used, and set to 

108A, also using well-known techniques. Based upon the 0 otherwise. The urgent pointer 356 is used to indicate a byte 

request message, the remote unit 108 A creates and transmits off^t f r0 m the current sequence number 312 at which urgent 

a wireless link request over a channel within the reverse data are to be found. The second 1 -bit flag is ACK 328 which 

uplink 114 and the reverse downlink 116. The hub station ^ set t0 1 wne n a packet bears an acknowledgment, and set 

104 receives the wireless link request over the reverse link. to 0 otherwise. For instance, a connection reply bears an 

Based upon the wireless link request, the hub station 104 acknowledgment, so its ACK bit 328 is set to 1. The third 

passes a request message to the appropriate content server i_bit flag is EOM 332 indicating the end of message when 

100 over the Internet 24. set to 1. The last packet of a message has the EOM bit 332 

In response, the content server 100 forwards the requested set to 1. All other packets will have the EOM bit 332 set to 

page or object to the hub station 104 over the Internet 24. 2Q 0. The fourth 1-bit flag is RST336 which is used to reset a 

The hub station 104 receives the requested page or object connection that has become confused due to a host delay or 

and creates a wireless link response. The hub station trans- breakdown. A host delay may occur due to congestion of 

mits the wireless link response over a channel within the packets over the network. A host breakdown (commonly 

forward uplink 110 and forward downlink 112. For example, referred to as a "crash") may be caused by a variety of 

in one embodiment of the exemplifying system, the hub 25 events, such as a power failure, a host processor reset, or an 

station 104 operates in accordance with assignee's error in the host application software. The fifth 1-bit flag is 

co-pending application entitled METHOD AND SYSTEM SYN 340 which is used to establish synchronization for a 

FOR FREQUENCY SPECTRUM RESOURCE connection request. A connection request has the SYN bit 

ALLOCATION, application Ser. No. 09/407,645, filed Sep. 340 set to 1 and ACK bit 328 set to 0 to indicate that the 

28, 1999, the entirety of which is hereby incorporated by 3Q piggyback acknowledgment 316 is not in use. As noted 

reference. above, the connection reply does bear an acknowledgment 

The remote unit 108 A receives the wireless link response with its SYN bit 340 and ACK bit 128 set to 1. The sixth 

and forwards a corresponding response message to the user 1-bit flag is FIN 344 which indicates release of a connection, 

terminal 11 8 A over the local area network 116. In one The FIN bit 344 is set to 1 to indicate that the sender has no 

embodiment of the exemplifying system, the process of 35 more data, and set to 0 otherwise. 

retrieving a web page or object is executed in accordance Flow control in TCP is handled using a variable-size 

with assignee's co-pending application entitled DISTRIB- sliding window. A 16-bit window field 348 is used to 

UTED SYSTEM AND METHOD FOR PREFETCHING indicate how many bytes a source host may send beyond the 

OBJECTS, application Ser. No. 09/129,142, filed Aug. 5, number of bytes acknowledged by a destination host on a 

1998, the entirety of which is hereby incorporated by 40 parallel reverse connection. The window field 348 is fol- 

reference. In this way, a bi-directional link between the user lowed by a checksum field 352 to provide reliable connec- 

terminal 118A and the content servers 100 is established. tions. An error in transmission can be detected by the 

To better understand the operation and advantages of the destination host by computing the checksum in the same 
invention, descriptions of example packet structures are way as the source host and comparing it against the value in 
provided. FIG. 3 is a diagram describing the structure of a 45 the checksum field 352, The value in the checksum field 352 
TCP packet 300. The term "packet" commonly refers to a is calculated by the source host by adding up all the data, 
unit of databits, including data and control signals. The term regarded as 16-bit words, and then converting the resulting 
"message" commonly refers to the user information or data sum to its l's complement, a standard computer operation, 
being communicated. A message may be of any length. If The checksum field 352 is followed by the above- 
necessary, the TCP layer fragments or splits the message into 50 described urgent pointer field 356. An options field 360 
multiple packets for transmission. follows the urgent pointer field 356 to communicate optional 

As shown in FIG. 3, the TCP header 48 comprises a data, such as buffer sizes during the link setup procedure, 

source port field 304 followed by a destination port field The options field 360 is followed by a data field 46. The data 

308, each having 16 bits, to identify the end points of a field 370 comprises the message being communicated over 

network connection. Each "host" computer may determine 55 the computer network. For instance, the message could be a 

for itself how to. allocate its ports. In a network, the term word processing document, a computer program, a digital 

"host" commonly refers to one of a group of computers image, digitized voice information for a phone call, an 

intended for running user applications (i.e., programs). The electronic mail message and so forth. 

TCP header 48 further includes a sequence number field 312. FIG. 4 is a diagram describing the structure of an IP 

TCP accepts arbitrarily long messages from user 60 packet or datagram. An IP datagram comprises an IP header 

applications, breaks them up into TCP datagrams not 38 followed by a data field 460. The IP header 38 includes 

exceeding 65,536 bytes, and sends each datagram as a a 20-byte fixed part and a variable length optional part. The 

separate packet. Hence, the sequence number 312 is a 32-bit 20-byte fixed part of the IP header 38 includes a versioo field 

word indicating the location of the datagram in the original 404 which indicates to which version of the Internet protocol 

message. 65 ihe datagram belongs. By including the version 404 in each 

Next, a piggyback acknowledgment field 316 is used by datagram, it is possible to change protocols while the 

a receiving computer to indicate receipt of a particular network is operating. Since the IP header 38 is not constant 
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in length, an IP header length (IHL) field 408 is provided to 6-byte source address 508 identifying the originator of the 

indicate the length of the IP header 38 in 32-bit words. By datagram follows tbe destination address 506. The source 

definition of the IP, the minimum value of the IHL 408 is S. address 508 is followed by a 2-byte type field 510 identi- 

The IHL field 408 is followed by a "type of service" field fying the type of data frame, such as for example Ethernet. 

412 which allows the host computer to inform the subnet- 5 Th e "ty pe " field 510 is followed by a variable length data 

work the kind of service required. Various combinations of ^ 504, The data field 504 can be from 46 to 1500 bytes 

reliability and speed are possible by predefined service in length depending on the size of the IP datagram. If the IP 

types. The "type of service" field 412 is followed by a "total datagrarn req uires more than 1500 bytes of data field 504, 

length" field 416 which includes the total number of all bits the datagram pac ketized into multiple MAC frames. The 

,n the datagram, i.e. both header and data bits_The maxi- data fcU m ^ foUowed b , ^ checksum 512 . ne 

mum size of the "total length field 416 » .65,536 bytes ^ ^ ^ &M J u ^ b ^ ^ 

The IP layer may break up each TCP datagram into host b &M M the dat ded as 16 bit word and 

smaller fragments for transmission across the network. The then tne resu|ti sum l0 1>s ^piemen., a 

elementary fragment unit is 8 bytes. Since the size of a standard ^ tio[) B 

datagram is a maximum of 65,536 bytes, there is a maximum ^ m ^ , ... . c 

of 8192 fragments per datagram. Hence, after the "total 15 ™ 6 15 * J* 1 °f dl ^?^f 1 ^ the st ™ ture ° f * 

length" field 416, an identification field 420 is used to allow ? V « fra ™ 6 »° * standard DVB frame comprises a DVB 

the destination host computer to determine to which data- * eader 602 and a data container 60 J ? 1 ^ ^VB header 602 

gram a newly arriving fragment belongs. All fragments b& Z™ ™* « 8 bli ^ nc P a " em . ^J 0 ^ lh * SynC 

belonging to the same datagram contain the same value in ^ n ? a " era fie ] d ™ are lt f e€ blt fie * ds > ^f^T.u 

the identification field 420 20 mdlcator 612 > the P a y load umt start indlcator blt 614 and the 

After an unused bit, two 1-bit fields follow the identifi- transport pnonty bit 616. 
cation field 420. The first 1-bit field is a "don't fragment" *°i^ W * g j!™ port P ^£Lt T u 

("DF") bit 424. When the DF bit 424 is set to 1, network PID/Oflset (PID) 618. In a standard DVB header the PID is 

gateways are instructed not to fragment the datagram ^ d t0 ^ ^ ^ ^ 

because the destination is incapable of reconstructing the 25 Following the PID field 618 are a 2-bit adaptation field 

fragments together into their original datagram. The second contro1 620 > a 2-bit scrambling control 622 and a 4-bit 

1-bit field is a "more fragments" ("MF") bit 428. The MF bit sequence number 624. 

428 is used as a double check against the total length field Next, the DVB frame comprises a data container 604. The 

416 to ensure that no fragments are missing from the 3Q data container provides 184 bytes of storage for data to be 

reconstructed datagram. Except for the last fragment, all transmitted. 

message fragments have the MF bit 428 set to 1. In one embodiment, the system comprises a hub station in 

The two 1-bit fields are followed by a "fragment offset" communication with the Internet. The hub station receives 

field 432 which indicates the location or order of the current data from the Internet and formats the data for transmission 

fragment in the datagram. As shown in FIG. 4, the "fragment 35 over a satellite communication link to a plurality of remote 

offset" field 432 consists of 13 bits and, hence, there is a units. At the remote units the data is converted back to its 

maximum of 8192 possible message fragments for each original Internet data format and transmitted by the remote 

datagram. The "fragment offset" field 232 is followed by a unit to end users. In other embodiments the remote unit may 

"time to live" field 436 which is a counter used to limit be, for example, hand held and use the internet data locally 

packet lifetimes. Typically, a network gateway destroys 40 at the remote unit. 

packets having a lifetime exceeding 255 seconds. TCP/IP data, if formatted appropriately, may be able to be 

After the IP layer at the destination host constructs a transmitted over a satellite link using DVB. Because DVB 

complete datagram, the IP network layer utilizes a protocol provides a standardized method of transmitting video data 

field 440 to indicate a typical transport protocol. TCP is one over a satellite link, costs of implementing a DVB satellite 

transport protocol, but other protocols such as transport 45 link should decrease as digital TV evolves. Thus, DVB can 

protocols specified by the Open Systems Interconnection be an attractive data transfer platform. 
(OSI) standard (e.g., ISO 8073) may be used. A header In one embodiment, the TCP/IP frames are formatted into 

checksum field 444 follows the protocol field 440 to verify DVB frames so as to align the beginning of each TCP/IP 

the validity of the IP header 400. The header checksum 444 data frame with the beginning of a DVB data frame and 

is useful because the IP header 38 may change at a gateway, 50 filling the DVB frame, or multiple DVB frames, until all the 

e.g., due to fragmentation into multiple fragments. A "source TCP/IP data is transmitted. This embodiment is attractive 

address" field 448 follows the header checksum 444 to because synchronization of TCP/IP and DVB frames is 

indicate the source network number and host number of the simple, because the beginning of a TCP/IP frame always 

data portion of the datagram. A destination address field 452 occurs at the beginning of a DVB frame. The size of a 

follows the source address field 444 to indicate the destina- 55 TCP/IP data frame is, on average, a different size than a 

tion network number and host number of the data portion. DVB frame. If the TCP/IP data spans multiple DVB frames, 

Finally, an options field 456 follows the destination address not all of the DVB data frames will be filled. This results in 

field 452. non-optimal utilization of the DVB data frames, usually 

FIG. 5 is a diagram describing the structure of a network resulting in a portion of a DVB frame being empty. In the 

header at the network access layer. The network header and 60 typical case, when the TCP/IP data does not fit exactly into 

data comprise a media access control (MAC) data frame a DVB frame, the unused portion of the DVB frame is 

500, typical of an Ethernet data frame. The IP datagram from wasted, decreasing the overall bandwidth of the communi- 

the IP layer is encapsulated into the MAC data frame. The cation system. 

MAC data frame 500 comprises a header 502 and data 504, According to another, embodiment of the invention, the 

and checksum 512. 65 DVB header 602 fields and data container 604 are assigned 

The header 502 comprises a 6-byte destination address values as described below. The DVB header 602 fields, 

506 identifying the desired designation of the datagram. A which are included at the start of every DVB frame 600, 
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remain the same as in a standard DVB header except for the 
PID field 618. In this embodiment of the invention, the PID 
field 618 is assigned a value indicating the location in the 
data container 604 where a new MAC frame begins. The 
values assigned to the PID are described in detail below. Use 
of the PID field to indicate the location where a new MAC 
frame begins within a DVB frame allows TCP/IP data to fill 
the DVB frames rather than to regularly transmit partially 
filled frames. In other embodiments, DVB header 602 fields 
other than the PID field 618 may be assigned a value 
indicating the location in the data container 604 where a new 
MAC frame begins One advantage of using the PID field 
618 to carry a value indicating the location in the data 
container 604 of the MAC frame is that standard off-the- 
shelf DVB receivers can be used to receive the DVB data 
stream. A standard DVB receiver is capable of providing 
data output when seemingly random, or disrupted, values are 
detected in the PID field 618. In addition, the PID field 618 
contains enough data bits to carry information indicating the 
location of the MAC frame anywhere within the DVB 
frame. Other DVB header fields may not contain a sufficient 
number of bits to carry the information. 

If one attempts to place information indicating location of 
the MAC frame into DVB header fields other than the PID 
fields 618, off-the-shelf DVB receivers may detect errors. 
The detected errors can be catastrophic, causing the DVB 
receiver to provide no output except perhaps an indication 
that an error has occurred. In such a case, the DVB data is 
not output by the receiver and the system becomes inoper- 
able. It may be possible to use DVB header 602 fields other 
than the PID filed 618 to contain the location value with this 
same advantage as long as the field does not interfere with 
the operation of a standard DVB receiver. 

The DVB data container 604 comprises two portions 
according to the invention: a first fragment header 606 and 
a data packet 608. The first fragment header 606 is trans- 
mitted at the beginning of the first fragment of a multiple 
fragment MAC data frame transmission. As will be dis- 
cussed below, one MAC data frame may be packetized into 
multiple DVB data frames to improve the efficiency of 
transmitting the MAC data frame in a DVB data frame 
format. Because the header information only needs to be 
transmitted once, it is transmitted with the first fragment 
only. On subsequent data frames, the header information is 
not repeated. 

The first fragment header 606 comprises a 16-bit packet 
length field 626, The value placed in the packet length field 
626 corresponds to the length of the data field 504 of the 
MAC data frame. Following the packet length field 626, a 
16-bit "type" field 628 contains the value from the 2-byte 
type field 510 of the MAC data frame. A destination address 
field 630 follows after the "type" field 628 and contains 4 
bytes of the 6 byte destination address 502 of the MAC data 
frame. The 4 bytes used may be either the 4 most significant 
bytes, the 4 least significant bytes or any other combination 
of 4 bytes from the 6 byte MAC destination address 502 
field. In the invention it is not anticipated that there will be 
more than 4 bytes of address space needed to identify all the 
remote units 108A-108N of the system. If growth in the 
number of remote units 108A-108N exhausts the 4 byte 
address space, other fields in the DVB header 602, not 
required to support operation of a standard DVB receiver, 
may be allocated to remote unit 108A-108N addressing. 

The remainder of the DVB data container is the data 
packet 608. The total length of a DVB data container is 188 
bytes. Because there is a 4 byte DVB header 602 transmitted 
in every DVB data frame 600, there is a maximum of 184 
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bytes available to carry other information. All of the 184 
bytes may comprise the data packet 608 if there is no first 
fragment header 606 required in the DVB data frame 600. If 
the DVB data frame 600 contains a first fragment of a MAC 

5 data frame, 8 bytes are allocated for the first fragment header 
606 and 176 bytes are available for the data packet 608. 

To better understand the operation of the invention, a 
description of an example set of MAC data frames pack- 
etized into DVB data frames is provided. FIG. 7 illustrates 

10 three example MAC data frames 702, 704 and 706. Pack- 
etizing three MAC data frames 702, 704 and 706 into five 
DVB data frames 708, 710, 712, 714 and 716 is described.' 

MAC data frame 702 comprises a header section 718 and 
a data section 720 corresponding to 502 and 504 of FIG. 5 

15 respectively. DVB data frame 708 comprises a DVB header 
722, a first fragment header 724 and a data packet 726, 
corresponding to 602, 606 and 608 of FIG. 6, respectively. 

The first portion of the DVB data frame 708 is the DVB 
header 722. The DVB header is at the beginning of every 

20 DVB data frame to conform to the DVB specification. 
Because this is the beginning of a MAC data frame, the first 
fragment header 724, as discussed in relation to FIGS. 5 and 
6, is built and located after the DVB header 722 in DVB data 
frame 708. With the DVB header 722, and the first fragment 

25 header, there are 176 bytes remaining in DVB data frame 
708 for data. In this example, there are more than 176 bytes 
of data in the MAC data section 720. Therefore the first 176 
bytes of data from the MAC data section 720 are carried in 
DVB data packet 726, filling DVB data frame 708. The 

30 additional data in 720 is carried in the next DVB data frame 
710. 

DVB data frame 710 begins with a DVB header 728. 
Because this is a continuation of MAC data frame 702, there 

35 is no first fragment header. With no first fragment header 
there are 184 bytes available in the DVB data packet 730 for 
MAC data. In this example, there are more than 184 bytes 
of data remaining in the MAC data portion 720 so the entire 
DVB data packet 730 is filled with data from MAC data 

^ frame 702. The additional data remaining in MAC data 
frame 702 is carried in DVB data frame 712. 

DVB data frame 712 begins with a DVB header 732. As 
described in relation to DVB data frame 710, there is no first 
fragment header and thus there are 184 bytes of data 

45 available for MAC data portion 720. In this example, there 
are less than 184 bytes of data remaining in MAC data 
portion 720. Thus the last segment of data portion 720 is 
located in the first portion 736 of DVB data packet 734. 
If the remaining portion 738 of the DVB data packet 734 

50 is at least 8 bytes in length, so as to accommodate an entire 
first fragment header, information corresponding to the next 
MAC data frame 704 is also carried in the 712. In this 
example, the remaining portion 738 of the DVB data frame 
712 contains more than 8 bytes. Thus the header 740 of 

55 MAC data frame 704 is converted into a DVB first fragment 
header 742. If there are at least 4 bytes still available in the 
remaining portion 738 of DVB data packet 734 following 
the first fragment header 742, MAC data 744 is carried in a 
section 746 of the remaining data portion 732. In this 

60 example, there is enough data in MAC data frame 738 to fill 
section 746 of DVB data frame 712. The data remaining in 
MAC data frame 704 is carried in the next DVB data frame 
714. 

DVB data frame 714 begins with a DVB header 748. 
65 Because frame 714 is not the first fragment of MAC data 
frame 704, there is no first fragment header. In this example, 
the remaining data portion 744 of MAC data frame 702 is 
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carried in the data packet 750 of DVB data frame 714. The data segment of the DVB data frame, with the data located 

remaining portion 752 of DVB data frame 714 does not between the beginning of the data packet and the first 

contain at least 8 bytes. Because there are less than 8 bytes fragment header containing data from the preceding MAC 

available, the remaining portion 752 of DVB frame 714 data frame. If the PID value is 4, the first fragment header 

cannot carry the entire first fragment header from MAC data 5 ^ located at the start of the data packet of the DVB data 

frame 706. In one embodiment the first fragment header is frame - If the PID value is 252 > there * 00 fot figment 

not split between two DVB data frames, therefore, the header and aI1 lhe data in the data P acket belongs to the 

remaining portion 752 of DVB data frame 714 is unused. In preceding MAC data frame. Thus the only DVB data frames 

other embodiments, the first fragment header may be which have a PID value of 252 are intermediate DVB data 

divided between two DVB data frames. 10 frames > containing fragments of a MAC data frame which 

• • ... 4 , t . ~ t c , i i . t spans multiple DVB frames, or the last DVB data frame of 

In the embodiment where the first fragment header » not / ff £ ^ framc ^ has , css than g fe avai]able 

divided between two DVB data frames, the procedure . 4 , & < 4 , 4 t . Ci , r* xr r> j * c ir.u 

. ., , , A A , , c L+£ „ W1 , in the data packet section of the DVB data frame. If there are 

described advances to the next DVB data frame 716. DVB . . 4 0 , r , .. . . . . . . i . * rwm j * 

j r . ... ■ »r» , , ™ , , at least 8 bytes available in the data packet of a DVB data 

data frame 716 begins with DVB header 754. The header , , M . nn XAAn , r ,„ . „ 

,,7 £i r .uj u* u u frame, and there is no more MAC data ready to transmit, a 

754 is followed by a first fragment . header 756 which 15 « t c tU , . n , ra , 4 i # 

i t \ M AO , , & __ 0 r x . A - , 4 f first fragment header is added to the DVB data packet with 

corresponds to the MAC header 758 of MAC data frame . ' ti . 4 . 4 4 , . r 4 , 4 

- ft , yi . f » * * j-, j , . - Air . ... , . a length field set to zero, indicating to the receiver that there 

706. Data from MAC data frame 706 is earned m a data 6 , t * , . , & .... 

i . * j -u j l is no more data presently being transmitted, 

packet 762 in the same manner as described above. _, , . « , . j ■ . . 

T , , „ , . mjn „ . , If there is a first fragment header in the data packet portion 

In the example discussed in FIG. 7 firsl (fragment headers 0 f the DVB data frame, the receiver parses the first fragment 

do not always occur at the start of a DVB data frame. hea der for the destination address 630, and the packet length 

Allowing first fragment headers to occur at a variable 62fi The deslinatioa address 630 identifies which remote 

location within a DVB data packet, provides for efficient unit tfae transmission is mlended for> ^ packet length field 

utilization of the DVB data frame. As illustrated in FIG. 7 62fi esents the Qumber of bytes C0Dtaine d in the MAC 

if first fragment headers could only occur at the beginning of daU field 504 ^ • tne kngth of the UAQ data field 

a DVB data frame, large portions of DVB data packets could ^ recdver fc ^ t0 reassemble the origiaal mesS age. 

go unused following the completion o one MAC data frame g fa a block ^ rf a hub stalion transmiUer 

to the beginning of the next DVB data frame. Placing first 4 m. ■ * . • i ♦ * - * 

& 6 . . - . . i * system. The transmitter system comprises an Internet uiter- 

fragments at a variable location within the data packet of a / _ Qft Ajf Ar , . %o „ tb^i 

, 4 „ . , a- • ^ * *u V»\m j » i ace 7 »0, a MAC to DVB converter 782, a controller 784, 

DVB data frame provides efficient use of the DVB data - QC , r^\rr> noo nn A . dc 

, r . . 30 memory 786, a standard DVb transmitter 7oo and a Rr 

frame, however, the receiving .system must be able to locate transmitter 790 ^ ImerDet 780 receives ^ 

the first fragment header in the data packet. formatted data from the Internet. The Internet interface 780 

According to one embodiment of the mvention, location provides any buffering or signal conditioning required by the 

of the first fragment header is provided by the PID field 618 hardware interface to the Internet. The output of the Internet 

in FIG. 6, of the DVB data frame. In other embodiments of 35 interface 780 is passed to the MAC to DVB converter 782. 

the invention, location of the first fragment header may be Using tne pr0 cedure described above, the MAC to DVB 

provided in other DVB header 602 fields which do not converter 782 formats the MAC data frames into DVB data 

adversely affect DVB transmission. In the embodiment frames. The controller 784 is in communication with the 

utilizing the PID field 618 for indicating location of the first to DVB converter 782. The controller 784 may be, for 

fragment header, as the DVB data frame is being built, if a 4Q exam pl e , a microprocessor, an application specific inte- 

firsl fragment header is located within the data packet 608 of grated circuit (ASIC), a field programmable gate array 

the DVB data frame, the value of the PID is set to corre- (FPGA), discrete logic, an analog circuit, or other control 

spond to the number of bytes into the data packet the circuitry. Communication between the controller 784 and 

beginning of the first fragment header is located. If the first the MAC t0 DVB converter 782 allows the controller 784 to 

fragment header follows immediately after the DVB header, 45 momtor the data transmission process such as, for example, 

then the PID is set to 4, which corresponds to the beginning detecting errors and detecting if a message is directed to the 

of the first fragment header following the 4 byte DVB hub station rather than to a remote unit through the RF link. 

header. If there is a first fragment header located somewhere -j^ controller 784 is also in communication with memory 

else within the data packet of the DVB data frame, the PID 786 s0 mat ^ a meS sage from the Internet was directed to the 

is set to a value corresponding to the offset from the start of 5Q hub sta tion, the controller 784 can direct that message to 

the DVB data frame to the start of the first fragment header. mem0 ry 786 or take appropriate action as required by the 

If the data packet contains only data, with no first fragment mesS age. The output of the MAC to DVB converter 782 is 

header then the PID is set to a value of 252. In one passed t0 a stan dard DVB transmitter 788. The standard 

embodiment valid PID values are multiples of 4, thereby D vb transmitter 788 prepares the DVB frame for transmis- 

aligning data on 4 byte boundaries. 55 sion over the lmk> ^ output 0 f the standard DVB 

As discussed previously, data formatted as described in transmitter 788 is transferred to the RF transmitter 790. The 

FIG. 7 is transmitted by the hub station 104 over the forward RF transmitter interfaces to an antenna 792 and transmits the 

link 110 to the satellite 106. The satellite receives the data DVB data frame over the wireless link to the remote units. 

from the forward link 110 and re-transmits them on a FIG. 9 is a flowchart describing the packetizing of a MAC 

forward downlink 112. The remote units 108A to 108N 60 data f rame m to a DVB data frame performed by the hub 

monitor one or more channels which comprise the forward station. The process starts in block 800. In block 802, a 

link in order to receive remote-unit specific data or broadcast MAC data frame is received from the network access layer. 

data from the hub station 104. plow continues to block 804, where the amount of space 

When data formatted as described in FIG. 7 is received by available in the current DVB data packet is determined. If 

a remote unit, the PID field 618 in the DVB header is read. 65 there are not at least 8 bytes available in the data packet, flow 

If the PID value is between 8 and 180, the receiver knows continues to block 806. In block 806 the data packet is sent. 

that a first fragment header begins at this location within the In block 808 the process advances to the next DVB frame 
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and the PID is set equal to a value of 4 indicating that the 
MAC frame is starting at the beginning of the DVB frame. 
Flow then continues back to block 804. In block 804 if there 
are at least 8 bytes available in the data packet floe continues 
to block 810. In block 810, the header and data are copied 
from the MAC frame to the DVB frame. In block 812, it is 
determined if all the MAC data, from the MAC frame being 
processed, has been copied. If all the MAC data has not been 
copied flow continues to block 814. In block 814 the DVB 
frame is transmitted. Flow continues to block 816 where the 
process advances to the next DVB frame. 

Flow then continues to block 818 where it is determined 
if after the remaining MAC data is copied to the DVB frame, 
will there be sufficient space remaining in the DVB frame 
for another header. If there will not be sufficient space 
remaining after the remaining MAC data is copied flow 
continues to block 820. In block 820 the PID is set equal to 
a value of 252 indicating that the entire DVB frame contains 
data from the same MAC frame. If in block 818 it is 
determined that there will be sufficient space remaining in 
the DVB frame after all the MAC data is copied flow 
continues to block 822. In block 822 the PID is set to a value 
equal to the number of bytes from the beginning of the DVB 
data frame to where a new MAC frame will begin. After the 
PID value is set in either block 820 or 822 flow continues to 
block 824. In block 824 the MAC data is copied to the DVB 
frame. Flow then continues to block 812. 

In block 812 if it is determined all the MAC data, from the 
MAC frame being processed, has not been copied flow 
continues to block 826. In block 826 it is determined if there 
are additional MAC frames available to be processed. If 
there are additional MAC frames available to be processed 
flow continues to block 802. If there are no additional MAC 
frames available flow continues to block 828. In block 828 
the DVB frame being processed is transmitted. Flow then 
continues to block 830. In block 30 a new DVB frame is 
started, and the PID is set to a value of 4. Flow then 
continues to block 802. 

FIG. 10 is a block diagram of a DVB receiver section of 
a remote unit. The DVB receiver section comprises an RF 
receiver 880, a standard DVB receiver 882, a DVB to MAC 
converter 884, a controller 886, memory 888 and a LAN 
interface/driver 890. The RF receiver 880 receives the 
wireless communication transmitted by the hub station. The 
output of the RF receiver 880 is passed to the standard DVB 
receiver 882. The standard DVB receiver 882 formats the 
data into DVB data frames. Data transmitted by the hub 
station is formatted to comply to the industry standard DVB 
format. As noted above, using the PID field to indicate the 
location of the start of a MAC from within the DVB data 
frame permits use of a standard DVB receiver. Use of the 
PID field does not interfere with normal operation of the 
DVB receiver. Use of fields other than the PID field may 
cause errors or otherwise make the DVB receiver inoper- 
able. As noted above, use of standard DVB receivers has 
several advantages, such as, for example, the reduced cost of 
the high volume standard receiver as compared to custom 
designs, and the ability to easily incorporate new advances 
in DVB receiver technology as they become available. 
Standard DVB receiver chips may be used, such as, for 
example, MITEL VP305, VP306 or any other receiver chip 
which complies with the DVB standard. 

The output of the standard DVB receiver 882 is passed to 
the DVB to MAC converter 884. In the DVB to MAC 
converter 884, the DVB data frame is defragmented into the 
original MAC data frame that was transmitted by the hub 
station as explained with reference to FIG. 11. The controller 


10 


15 


20 


25 


886 is in communication with the DVB to MAC converter 
884. Communication between the controller 886 and the 
DVB to MAC converter 884 allows the controller 886 to 
monitor data reception by the remote unit. The controller 
886 monitors, such as, for example, errors in the received 
message and if the message was directed to the remote unit 
or to be transferred to the LAN. The controller is also in 
communication with memory 880. If a transmission is 
intended for the remote unit, such as, for example, a soft- 
ware upgrade for the remote unit, the controller 886 detects 
that the message is intended for the remote unit and directs 
the DVB to MAC converter 884 to route the message to 
memory 888. Messages that are intended for the LAN pass 
from the DVB to MAC converter 884 to the LAN interface/ 
driver 890. LAN interface/driver 890 provides signal con- 
ditioning and the required interface and driver circuitry to 
interface the remote unit to a LAN. The controller may be, 
for example, a microprocessor, an application specific inte- 
grated circuit (ASIC), a field programmable gate array 
(FPGA), discrete logic, an analog circuit, or other control 
circuitry. 

FIG. 11 is a flowchart describing the defragmentation of 
a MAC data frame formatted into a DVB data frame 
performed by the remote unit. The process starts at block 
900. In block 902 a DVB data frame is received. Flow 
continues to block 904, where it is determined if the DVB 
frame received contains data which is a continuation from 
the MAC data contained in the previous DVB frame. If the 
DVB frame received does not contain data which is a 
30 continuation of the MAC data contained in the previous 
DVB frame flow continues to block 906. In block 906 it is 
determined if a MAC frame defragmentation, or reassembly, 
is in process. If a MAC frame reassembly is in process flow 
continues to block 908. In block 908 the MAC frame which 
35 is being reassembled is discarded. The frame is discarded 
because the reassembly process is not complete, however, 
the DVB frame received does not contain data which is a 
continuation from the MAC data from the previous frame. In 
the manner described, a remote unit is able to synchronize 
itself to an incoming data stream if the remote unit is coming 
online initially, following a remote unit reset, or if a DVB 
data frame is lost or corrupted. Flow then continues to block 
910. 

If in block 906 it is determined that a MAC frame 
45 reassembly is not in process flow continues to block 910. In 
block 910 it is determined if there are more MAC frames in 
the DVB frame being processed. If there are no more MAC 
frames in the DVB frame, as indicated by a length field of 
zero or the end of the DVB frame has been reached, then 
flow continues to block 902. If it is determined that there are 
more MAC frames in the DVB frame being processed flow 
continues to block 912. In block 912 it is determined if the 
entire MAC frame is contained in the DVB frame being 
processed. If the entire MAC frame is contained in the DVB 
55 frame being processed flow continues to block 914. In block 
914 the data from the DVB frame is copied to the MAC 
frame. In block 916 the completed MAC frame is sent to the 
IP layer. Flow then continues to block 910. If in block 912 
it is determined the entire MAC frame is not contained in the 
60 DVB frame being processed, but spans multiple DVB 
frames, flow continues to block 918. In block 918 the first 
fragment of the MAC frame is copied to a MAC reassembly 
buffer. Flow then continues to block 902 to receive the next 
DVB frame. 

Returning to block 904, if the DVB frame received does 
contain data which is a continuation of the MAC data 
contained in the previous DVB frame flow continues to 


40 


50 


65 


03/12/2004, EAST Version: 1.4.1 


US 6,665,292 Bl 


15 


16 


block 920. In block 920 it is determined if a MAC frame 
reassembly is in process. If a MAC frame reassembly is in 
process flow continues to block 922. In block 922 the MAC 
data from the DVB frame is copied to the MAC reassembly 
buffer. Flow continues to block 924 where it is determined 
if the MAC frame is complete as indicated by a PID value 
not equal to 252 or if there is data remaining in the DVB 
frame. If the MAC frame is complete flow continues to 
block 926. In block 926 the MAC frame is sent to the IP 


2. The hub station of claim 1 wherein the MAC data frame 
is an Ethernet frame. 

3. The hub station of claim 1 wherein the DVB transmitter 
conforms to industry DVB standards. 

4. The hub station of claim 1 wherein the wireless 
communications link is a satellite link. 

5. The hub station of claim 1 wherein the value is 
contained in the PID field of the DVB frame. 

6. In a hub station of a communication system which 


layer. Flow then continues to block 928. If, in block 924, it 10 transmits data to a plurality of remote units, a method of 
is determined that the MAC frame is not complete flow transmitting data comprising: 


20 


continues to block 928. Returning to block 920, if it is 
determined a MAC frame reassembly is not in process flow 
continues to block 928. 

In block 928 it is determined if there are more MAC 15 
frames in the DVB frame being processed. If there is 
additional MAC data in the DVB frame being processed 
flow continues to block 906. If there is no additional MAC 
data in the DVB frame being process flow continues to block 
902. 

The invention may be embodied in other specific forms 
without departing from its spirit or essential characteristics. 
The described embodiment is to be considered in all respects 
only as illustrative and not restrictive and the scope of the 
invention is, therefore, indicated by the appended claims 25 
rather than the foregoing description. All changes which 
come within the meaning and range of equivalency of the 
claims are to be embraced within their scope. 

What is claimed is: 

1. A hub station in a communication system comprising: 
a MAC to DVB converter having an input port configured 
to be coupled to an internet interface and an output port 
configured to produce a standard DVB data frame by 
accepting a MAC data frame received from the input 35 
port and packetizing data within the MAC data frame 
into at least one DVB data frame, wherein the MAC 
data is packetized within DVB frames such that frag- 
ment headers occur at variable locations within the 
DVB frames, and wherein a value is stored within the ^ 
DVB frame which indicates location of the fragment 
header within the DVB frame; and 
a DVB transmitter having an input port coupled to the 


30 


receiving a block of Internet data from a network; 

converting the Internet data into a standard DVB data 
format, wherein the Internet data is formatted within 
DVB frames such that fragment headers occur at vari- 
able locations within the DVB frames, and wherein a 
value indicating location of the fragment header is 
stored within the DVB frame; and 

transmitting the DVB data over a wireless communication 
channel. 

7. The method of claim 6 wherein the Internet data is 
formatted as an Ethernet frame. 

8. The method of claim 6 wherein the wireless commu- 
nication channel is a satellite link. 

9.. The method of claim 6 wherein the value is contained 
in the PID field of the DVB frame. 

10. A hub station in a communication system which 
transmits data to a plurality of remote units, comprising: 

means for receiving a block of Internet data from a 
network; 

means for converting the Internet data into a standard 
DVB data format, wherein the Internet data is format- 
ted within DVB frames such that fragment headers 
occur at variable locations within the DVB frames, and 
wherein a value indicating location of the fragment 
header is stored within the DVB frame; and 

means for transmitting the DVB data over a wireless 
communication channel. 

11. The method of claim 10 wherein the Internet data is 
formatted as an Ethernet frame. 

12. The method of claim 10 wherein the wireless com- 
munication channel is a satellite link. 

13. The hub station of claim 10 wherein the value is 


output port of the MAC to DVB converter and config- 
ured to accept the at least one standard DVB data frame 45 contained in the PID field of the DVB frame 
and having an output port configured to transmit the 

DVB data frames over a wireless communication link. ***** 
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